home *** CD-ROM | disk | FTP | other *** search
/ Turnbull China Bikeride / Turnbull China Bikeride - Disc 2.iso / BARNET / ARMLINUX / MAIL / 9804 / 000141_owner-linux-arm…r.rutgers.edu _Thu Apr 30 09:04:26 1998.msg < prev    next >
Internet Message Format  |  1998-05-13  |  3KB
  1. Return-Path: <owner-linux-arm-outgoing@vger.rutgers.edu>
  2. Received: from orava.funet.fi (orava.funet.fi [128.214.248.46])
  3.     by odie.barnet.ac.uk (8.8.6/8.8.6) with ESMTP id JAA09678
  4.     for <willy@odie.fluff.org>; Thu, 30 Apr 1998 09:04:25 +0100
  5. Received: from vger.rutgers.edu ([128.6.190.2]:17249 "EHLO vger.rutgers.edu" ident: "root") by orava.funet.fi with ESMTP id <390623-18338>; Thu, 30 Apr 1998 11:02:07 +0300
  6. Received: by vger.rutgers.edu id <971629-8838>; Thu, 30 Apr 1998 03:35:14 -0400
  7. Received: from tazenda.demon.co.uk ([158.152.220.239]:3179 "HELO kings-cross.london.uk.eu.org" ident: "exim") by vger.rutgers.edu with SMTP id <971621-8838>; Thu, 30 Apr 1998 03:35:00 -0400
  8. Received: from kings-cross.london.uk.eu.org [127.0.0.1] (phil)
  9.     by kings-cross.london.uk.eu.org with esmtp (Exim 1.71 #1)
  10.     id 0yUo9e-0006SV-00; Thu, 30 Apr 1998 08:53:18 +0100
  11. X-Mailer: exmh version 2.0zeta 7/24/97
  12. To: linux-arm@vger.rutgers.edu
  13. Subject: Re: uaccess ramblings 
  14. In-reply-to: Your message of "Wed, 29 Apr 1998 23:52:14 BST."
  15.              <199804292252.XAA00790@raistlin.armlinux.org> 
  16. Mime-Version: 1.0
  17. Content-Type: text/plain; charset=us-ascii
  18. Date:     Thu, 30 Apr 1998 08:53:18 +0100
  19. From: Philip Blundell <Philip.Blundell@pobox.com>
  20. Message-Id: <E0yUo9e-0006SV-00@kings-cross.london.uk.eu.org>
  21. X-Orcpt: rfc822;linux-arm@vger.rutgers.edu
  22. Sender: owner-linux-arm@vger.rutgers.edu
  23. Precedence: bulk
  24. X-Loop: majordomo@vger.rutgers.edu
  25. Status: RO
  26.  
  27. Russell King wrote:
  28.  
  29. >Since the kernel accesses physical RAM from time to time using the get_user
  30. >and put_user macros, replacing them with a LDRT/STRT instruction will cause
  31. >a fault.
  32.  
  33. That's a shame.  In fact I think I have a plan that will still allow quite an 
  34. improvement.  I'll try to implement it today and make a patch.  Access to 
  35. physical RAM is never allowed in USER_DS (I assume) and the access_ok() check 
  36. will catch that.  So in put_user() we can check whether the address being 
  37. accessed is above 0x02000000 - if so it must be a kernel access to physical 
  38. RAM and can never fault so we can just do a plain STR (don't even have to 
  39. stack the link register in fact).  If it's below 0x02000000 it's an access to 
  40. logical RAM; we can use STRT and let MEMC signal an exception if it's a bad 
  41. access.  This check will cost us a TST/BNE but that's still less than the 
  42. current scheme by quite a way since it avoids all this fiddling with registers 
  43. and getting values out of current->tss.uaccess->* (which requires two pointer 
  44. dereferences).
  45.  
  46. Does that sound reasonable or am I still overlooking something?  I suppose 
  47. there's a slight danger of taking an address exception in the "physical RAM" 
  48. case I described but I imagine we can allow that to go untrapped and cause an 
  49. Oops to be honest since only a kernel bug could cause it.
  50.  
  51. Out of interest, where does the kernel access physical RAM with get_user()?
  52.  
  53. >They are redundant and have now been removed.
  54.  
  55. Thanks.
  56.  
  57. p.
  58.  
  59.  
  60. unsubscribe: body of `unsubscribe linux-arm' to majordomo@vger.rutgers.edu